Add getCardSettings utility for nested card settings format#83669
Add getCardSettings utility for nested card settings format#83669blimpich merged 9 commits intoExpensify:mainfrom
Conversation
|
sorry for the ping guys @joekaufmanexpensify @suneox , you can ignore this |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3156a2d5e7
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const workspaceAccountID = useWorkspaceAccountID(policyID); | ||
| const [lastSelectedExpensifyCardFeed] = useOnyx(`${ONYXKEYS.COLLECTION.LAST_SELECTED_EXPENSIFY_CARD_FEED}${policyID}`); | ||
| const [lastSelectedCardSettings] = useOnyx(`${ONYXKEYS.COLLECTION.PRIVATE_EXPENSIFY_CARD_SETTINGS}${lastSelectedExpensifyCardFeed}`); | ||
| const lastSelectedSettings = getCardSettings(lastSelectedCardSettings); |
There was a problem hiding this comment.
Resolve last-selected fund from the nested feed settings
This hook now calls getCardSettings(lastSelectedCardSettings) without a feedCountry, so when the backend returns the nested shape described in this PR (for example US / TRAVEL_US buckets), the helper returns the root object and lastSelectedSettings?.paymentBankAccountID can be missing. In that case the lastSelectedExpensifyCardFeed branch is skipped and we fall back to another fund ID, which can open the wrong feed’s card data after Phase 2 rollout. Pass the selected feed country when reading settings here (and in the related call sites) so default feed selection remains correct for nested payloads.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch on the theory, but this is intentional for Phase 1. Today the backend only sends the flat format, so calling getCardSettings without feedCountry correctly returns the root object with paymentBankAccountID intact.
In Phase 2 when the backend starts sending nested format (US, TRAVEL_US keys), we'll update these call sites to pass the appropriate feedCountry. This PR just sets up the abstraction layer so that transition is a small diff rather than a large refactor.
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
| return !!(policy?.areExpensifyCardsEnabled && cardSettings?.paymentBankAccountID); | ||
| } | ||
|
|
||
| function getCardSettings(cardSettings: OnyxEntry<ExpensifyCardSettings>, feedCountry?: string): ExpensifyCardSettingsBase | undefined { |
There was a problem hiding this comment.
can this be an onyx selector instead?
There was a problem hiding this comment.
It could work as a selector today since no call site passes feedCountry yet — all 10 usages would just be useOnyx(..., { selector: getCardSettings }).
But in Phase 2 when some call sites need to pass feedCountry, those would need useCallback wrappers to keep the selector referentially stable:
const selector = useCallback(
(cs: OnyxEntry<ExpensifyCardSettings>) => getCardSettings(cs, feedCountry),
[feedCountry]
);
const [settings] = useOnyx(`...`, { selector }, [feedCountry]);Also right now without feedCountry it's essentially an identity function, so there's no memoization benefit from making it a selector — Onyx would still re-render on any settings change.
Keeping it as a plain utility for now keeps things simple and avoids a second refactor when Phase 2 lands. But happy to convert if you'd prefer the selector pattern regardless.
There was a problem hiding this comment.
yeah, I just think the change would be smaller overall because you would not have to rename everything from cardSettings to settings, but all good.
|
Almost done for the day, I'll take a look tomorrow |
|
Still have some typescript issues? |
|
done |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚧 @blimpich has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Deployed to staging by https://github.com/blimpich in version: 9.3.28-0 🚀
|
|
🚀 Deployed to staging by https://github.com/blimpich in version: 9.3.30-0 🚀
|
|
🚀 Deployed to production by https://github.com/blimpich in version: 9.3.30-3 🚀
|
Explanation of Change
Phase 1 of fixing the shared Onyx key collision between Expensify Card and Travel Invoicing feeds (
private_expensifyCardSettings_{workspaceAccountID}). This PR adds agetCardSettings(cardSettings, feedCountry?)utility and updates all Expensify Card page components to read data properties through it instead of directly from the flatcardSettingsobject.No functional change — the utility falls back to the flat root when no
feedCountryis provided. This sets up the abstraction layer so that when Phase 2 lands (Auth sends nested format with keys likeUS,TRAVEL_US), the frontend is already resilient to both formats.Fixed Issues
$ #81472
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
N/A — no UI change
Android: mWeb Chrome
N/A — no UI change
iOS: Native
N/A — no UI change
iOS: mWeb Safari
N/A — no UI change
MacOS: Chrome / Safari
N/A — no UI change